Currently, 3rd generation cellular communication systems are being rolled out to further enhance the communication services provided to mobile phone users. The most widely adopted 3rd generation communication systems are based on Code Division Multiple Access (CDMA) and Frequency Division Duplex (FDD) or Time Division Duplex (TDD) technology. Further description of CDMA, and specifically of the Wideband CDMA (WCDMA) mode of UMTS, can be found in ‘WCDMA for UMTS’, Harri Holma (editor), Antti Toskala (Editor), Wiley & Sons, 2001, ISBN 0471486876.
One enhanced feature being developed in the 3rd generation partnership project (3GPP) standard is the provision of multimedia services to mobile phone users, utilising Multimedia Broadcast Multicast Service (MBMS).
In MBMS, point-to-multipoint delivery can be made where a wireless communication unit (termed user equipment (UE) in 3GPP parlance) is able to perform soft combining of received transmissions from multiple base stations. In release-6 of 3GPP, this form of combining is referred to as Layer-1 Combining or Transport Channel Combining (in TDCDMA). Furthermore, MBMS over a Single Frequency Network (MBSFN) has been introduced in release-7 of the specifications, for TDCDMA and WCDMA. In MBSFN, identical waveforms are transmitted simultaneously from multiple base stations and soft combined by the UE.
FIG. 1 illustrates an outline of a known MBMS point-to-multipoint system where delivery of data content is performed using a Forward Access Channel (FACH) frame protocol 115 to enable soft combining at the wireless communication unit (UE) 130. A requirement for soft combining to work is that the radio transmissions from the different base stations, referred to as Node Bs 120 in 3GPP parlance, within a combining cluster of cells, take place simultaneously. The scheduling of radio transmissions is performed by a radio network controller (RNC) 110, which identifies the bits (termed transport blocks) contained in the broadcast/multicast content 105 that should be sent in each 10 msec. radio frame. The transport blocks are then transmitted to each Node B 120 using a framing protocol: the Forward Access Channel (FACH) Frame Protocol 115, as defined in 3GPP TS25.435 ‘UTRAN Iub Interface User Plane Protocols for Common Transport Channel Data Streams’. The FACH is the name of the transport channel that is used to convey the bits to the user.
Every FACH Frame Protocol message 115 carries a frame number stamp, the CFN, which informs the Node B 120 of the particular frame in which the transmission should take place. The interface between the RNC 110 and the Node B 120 is called the Iub. According to the topology of the Iub the transfer delay of the FACH frame protocol from the RNC 110 will vary amongst the set of Node Bs 120. For example, with a star topology, with a small number of Node Bs 120 to be addressed and a relatively low number of intermediate nodes, the delay variation across the set of Node Bs 120 is expected to be small.
However, if the Node Bs 120 are configured in a chain topology, the delay to the Node B(s) 120 at the end of the chain is greater than those at the head of the chain. It is noteworthy that, when the Node B 120 supports multiple cells (sectors), individual frame protocols shall be sent for each cell. MBMS combining is restricted to data sourced from a single RNC 110.
In the TDCDMA mode of MBMS, it is relatively straightforward to align the framing of all of the Node Bs 120 by using an external synchronisation signal, such as may be derived from a geo-stationary position system (GPS), for example as defined in 3GPP TS25.402 ‘Synchronisation in UTRAN Stage 2’. Furthermore, not only can the frame boundaries be synchronised between Node Bs 120, but the System Frame Numbers (SFN) can also be made equal. When a Node B 120 receives a FACH Frame Protocol message 115 it determines the earliest SFN value that satisfies the criteria:                SFN mod 256=CFN mod 256where: ‘mod’ means take the modulus.        
Since all Node Bs 120 agree on the SFN, the CFN stamp should be the same to each Node B 120 to support the simultaneous transmission of the transport blocks carried within the FACH Frame Protocol 115.
For WCDMA the framing and the frame numbers of the individual Node Bs 120 are not aligned. This complicates the behaviour of the RNC 110, as the RNC 110 needs to track the relative timing of each Node B 120 individually. Furthermore, the RNC 110 needs to stipulate offsets with respect to frame boundaries that should be employed (e.g. a different offset in each Node B 120). However, in other respects the behaviour is the same as for TDCDMA. The remaining of the background discussion will be focused on TDCDMA.
Each Node B 120 is able to buffer the frame protocol messages 115 for a number of frames waiting for the correct SFN to come round. The maximum configurable buffer size is ‘128’ frames, since it is ambiguous whether a frame has arrived early or late when the buffer is any larger (the range of CFN values being ‘0’ to ‘255’). If the data arrives too late at the Node B 120, the data falls outside the buffer and the data is discarded. Furthermore, the ability of the Node B 120 to contribute to the soft combining for the received data at the UE is also lost. Therefore, a key task of the RNC 110 is to ensure that the data in the FACH Frame Protocol message 115 arrives at each Node B 120 within the respective Node B 120's receive buffer. To facilitate this task, the RNC 110 needs to know the transit delay from the RNC 110 to each Node B 120 for the FACH Frame Protocol 115, as well as the framing of each Node B 120 relative to its own framing, so that the CFN can be set correctly.
In 3GPP the RNC 110 determines a relative framing between itself and a Node B 120, using the RNC-Node B Node Synchronisation procedure 200, as illustrated in FIG. 2. In FIG. 2, the RNC 110 employs the RNC to Node B synchronisation procedure 200, in order to determine a relative phase of its own timing (RFN) and that of the Node Bs (BFN). RFN is the RNC Frame Number counter, with a range of ‘0’ to ‘4095’ frames. BFN is the Node B Frame Number counter, with a range of ‘0’ to ‘4095’ frames. The RNC 110 sends a downlink (DL) ‘DL NODE SYNCHRONISATION’ frame 210 to the Node B 120, and the Node B 120 returns an uplink (UL) ‘UL NODE SYNCHRONISATION’ frame 220. When the RNC 110 has measured a round-trip delay (RNC 110 to Node B 120 and back to the RNC 110) using the procedure of FIG. 2, the RNC 110 is able to calculate the single trip delay (230, 240) by dividing this by two—assuming a symmetrical DL/UL Iub.
This procedure is repeated for each Node B 120. After following the known procedure in FIG. 2, the RNC 110 now knows the relative framing of itself to each Node B 120, as well as the round-trip time to each Node B 120. However, the RNC 110 does not know the SFN in each Node B 120, but this is not needed since the SFN is locked to the known BFN.
There are now two options open to the RNC 110:                (i) Send individual frame protocol messages to each Node B 120, thereby ensuring that each message arrives with just enough time for the Node B 120 to process the received frame and transmit the processed frame in the correct frame, or        (ii) Send all the frame protocol messages 115, with the same CFN stamp, at the same time. The timing of the transmission is governed by the Node B 120 that has the greatest transfer time from the RNC 110 to itself.        
When option (ii) is followed, the Node B 120 that has the shortest transit time needs to buffer the incoming frames for the longest time. The advantage of option (ii) is that the RNC 110 only needs to track the greatest transit time amongst a set of Node Bs 120. As long as the frame protocol message 115 having the greatest transit time arrives in sufficient time at the Node B 120, then the frame protocol message 115 having the greatest transit time will also arrive in sufficient time at all the other Node Bs 120. A minor disadvantage of option (ii), when compared to option (i), is the requirement to include memory at the Node B 120 to buffer frames. The memory, as stated earlier, is upper-bounded by ‘128’ frames worth of data (which for a 500 kb/sec. service equates to about 80 kB, so that the memory demands are unlikely to be onerous in typical implementations).
In a real system, it is expected that the transit time to each Node B 120 may vary with time, due to jitter on the backhaul (IUB) link. Furthermore, the relative framing of the RNC 110 to the Node B 120 needs to be continuously reassessed, due to the relative drift in their respective clocks. Therefore, it is useful to periodically repeat the Node synchronisation procedure of FIG. 2. By tracking the transit delays to each Node B 120, or in particular the Node Bs 120 which are known to have the greatest delay, the RNC 110 is able to schedule the time of transmission of the frame protocol messages so that the latency can be minimised. In principle, the RNC 110 could assume a very large worst-case transit time to the set of Node Bs 120 and employ this all the time. However, the disadvantage of this approach is the additional latency incurred.
In the aforementioned known architecture of FIG. 1, there is a bidirectional link between the RNC 110 and every Node B 120. This bidirectional link is used to configure the Node B using the Node B application protocol (NBAP). The bidirectional link is used by the user plane protocol to send the FACH Frame Protocol and the control frame protocols, such as those used by the node synchronisation procedure of FIG. 2.
However, the architecture does not scale well to large numbers of Node Bs 120, which may be required for the broadcasting of mobile television. One problem is that the RNC 110 needs to operate a FACH Frame Protocol user plane to each Node B 120 individually. Furthermore, if a backhaul link is shared by two or more Node Bs 120, then the capacity of the shared link must accommodate the multiple copies of the same frame protocol. Note that whilst the frame protocol may be the same, the transport layer on which each frame is carried is different—there is a unique transport layer address for each Node B 120. If IP (Internet Protocol) transport is employed, unique unicast IP addresses/UDP port numbers are used. These drawbacks may be addressed by using IP multicast for the transmission of the FACH Frame Protocol.
Referring now to FIG. 3, a simplified Internet Protocol (IP) network 300 is illustrated, where IP multicast on the Iub is employed, the RNC 110 generates a single FACH Frame Protocol (FP) message 115 and this is mapped onto the Internet Protocol (IP) transport layer using an IP multicast address. All the Node Bs 120 that are required to transmit the content of the frame to a UE 130 are informed of this address and they join the multicast group for this address (using the IGMP protocol). The frame is sent from the RNC 110 to a first router 310, which then duplicates the IP data packet and transmits 315 the duplicated IP data packet to other routers 320 that have been identified as lying on the path to a Node B 120 that has joined the multicast group. Complex routing algorithms are therefore employed to determine the optimum routing path for the multicast FP frames. Hence, a tree hierarchy is established by IGMP linking the RNC 110 to the Node Bs 120 using a mesh of intermediate routers 320.
The IP network may also be conveniently realised using a satellite distribution network 400, as illustrated in FIG. 4. IP multicast distribution over the Iub has been proposed for 3GPP by Huawei in R3-071035, RAN3 Meeting 56, Kobe, 7 May 2004, in a document titled ‘Proposal on Iub efficiency for MBMS in IP RAN’. In FIG. 4, an IP multicast transmission 105 is sent to the RNC 110 and translated to a FACH FP message 115 to be forwarded to a satellite head end 405. The satellite earth station 410 then transmits the FACH FP message on a satellite uplink channel 415 to a satellite 420, which relays the FACH FP message on a number of downlink channels 425 to a number of Node Bs 120. With this proposed approach, the previously indicated option (ii) of sending packets to all Node Bs starting from the same point in time is effectively followed.
When FACH frames are delivered over the multicast network, a bidirectional unicast link from the RNC 110 to each Node B 120 is also required. Therefore, two Iub connections per Node B 120 are required, a first multicast Iub, carrying FACH frames on a unidirectional link, and a second unicast Iub, providing a bidirectional link and used to manage the Node B (NBAP). This second unicast Iub is used for user plane control Frame Protocols (e.g. DL & UL Node Synchronisation messages).
The inventor has recognised that, in the architecture of FIG. 4, the RNC 110 is unable to determine the transit time for each Node B 120 for the multicast FACH traffic. In principle a DL Node Synchronisation message may be sent over the multicast downlink and a response can be returned using the UL Node Synchronisation message. However, the round trip delay (RTD) is no longer balanced equally between downlink and uplink and the required metric cannot simply be obtained by halving the RTD.
Thus, a need exists for providing a mechanism to determine timing for MBMS point-to-multipoint distribution using IP multicast on an Iub link.